Skip to main content

xDai Bridge

info

The Legacy xDai bridge can be found at https://bridge.legacy.gnosischain.com/

The Legacy xDai bridge is a native Dai bridge from Ethereum that is used to mint and burn xDai, the native asset used for gas and transaction fees on Gnosis.

xDai Bridge Diagram

Once Dai is bridged into the xDai bridge, the xDai bridge contract on Gnosis notifies the block rewards contract. The consensus algorithm then mints xDai to the user's corresponding address on Gnosis in the next block.

Key Information​

Overview​

Detail
Frontend URLhttps://bridge.gnosischain.com
Trust Model4-of-7 Validator Multisig
Governance8-of-16 Multisig
Governance ParametersValidator Set, Daily Limits, Fees
Bug BountyUp to $2m
Bug ReportingImmunefi

Key Contracts​

Ethereum​

ContractEthereum Address
Proxy Contracteth:0x4aa42145Aa6Ebf72e164C9bBC74fbD3788045016
Validator Management Contracteth:0xe1579dEbdD2DF16Ebdb9db8694391fa74EeA201E
Admin Multisignature Walleteth:0xff1a8EDA5eAcdB6aAf729905492bdc6376DBe2dd
info

The current deployment of xDAI bridge contract is from tokenbridge-contracts/xdaibridge-upgrade-sdai, with the commit hash bf602f35e624cc6c58c827e7c56b23c8b1afa69a

References:

Savings xDAI​

Application: https://agave.finance/sdai/

Rationale​

MakerDAO’s DSR current rate is 5%. Since the increase of the DSR to ~3.5%, ~7M DAI have fled out of the xDAI bridge, as can be seen on this dashboard. Bridging the DSR yield into Gnosis Chain will help regain these deposits. In order to provide the needed catalyst for Gnosis Chain Defi to boom, interest rates on Gnosis Chain have to pick up or reach parity with Ethereum or other chains with higher borrowing demand.

Introducing Savings DAI (sDAI), a DSR(Dai Savings Rate) module in xDAI Bridge between Ethereum and Gnosis Chain.

By depositing most of the DAI in xDAI bridge into sDAI vault from Spark Protocol on Ethereum, which is a ERC4626 vault depositing all DAI into the Maker DSR, interest is accrued from Maker DSR and relayed to Gnosis Chain. xDAI holders on Gnosis Chain can mint sDAI with their xDAI, and enjoy the interest accumulating from Ethereum.

Check out the proposal from Karpatkey to Deposit DAI of the xDAI bridge in sDAI vault from Spark

Interest rate​

Assuming the amount of “Savings DAI on GC” minted is lower than the one held by the bridge, then the yield will be higher than the Dai savings Rate. The bridge currently holds roughly 25M DAI and the DSR yield is 5%, assuming 25M get wrapped into sDAI and only 10M xDAI get deposited into the vault on GC, the yield will be 12.5% .

The expectation is that the sDAI rate will always be higher on GC than Mainnet, as only if almost 100% of all DAI bridged is staked will we achieve rate parity.

Considering the current 25M DAI sitting in the bridge, that represents ~1.25M yearly to incentivise GC.

DSR yield is risk-free if you are already holding DAI. All the risks derived from the collateral are borne by all DAI holders, regardless of them depositing in the DSR. Karpatkey team have written a research piece here. The only newly introduced risk is smart contract risk in how the integration is made with the sDAI vault on Ethereum and the implementation of the sDAI vault on GC.

Architecture​

Ethereum​

A new implementation upgrade in xDAIForeignBridge contract: SavingsDAI Connector is added as a dependency in the contract. Compare to the old implementation of the Compound Connector, the payInterest function in SavingsDai Connector is used to transfer interest received from vault to receiver address on Gnosis Chain rather than to receiver address on Ethereum.

sDAI is deployed on Ethereum. Any future DAI deposited to the Bridge will be wrapped into sDAI, with caveat that it will always keep the buffer of the minimumCashThreshold when investing.

minimumCashThreshold: This value determines what is the recommended amount of DAI that should be held in the bridge at all times, in order to create a buffer for withdrawals without added operations and thus lower gas costs.

Gnosis Chain​

There are two contracts being deployed on Gnosis.

The first one is the sDAI vault, also an ERC 4626 which is the most popular standard for vaults which makes it extremely useful for Defi integrations from Lending Protocols like Agave and Spark,  to DEXes like Curve and Balancer with their boosted pools. The only modification to the standard vault (OZ implementation) is that it will allow for direct deposits and withdrawals in xDAI, rather than exclusively the ERC20 WXDAI.

The second contract is the Interest Receiver. This will be the address provided on Mainnet bridge as the interest receiver. What this contract does is quite simple, it distributes the balance it holds in xDAI and WXDAI into sDAI at a fixed block rate that gets updated every 1-2 days to adjust for interest rate changes coming from mainnet. The goal of this contract is to not make it possible to front run the bridging process of the interest, and to make sure there is a fairly frequent update of the sDAI shares value and exchange rate. This contract has the perk of being very easy to switch for a different one by simply setting a new receiver on the bridge, without impacting any of the operations. This means if we want to make modifications such as add a fee or normalize rates in the future, that will be very easy to plug-in.

Role and responsibilities​

xDAI/wxDAI holder

  1. Deposit xDAI/wxDAI and get sDAI shares:
    1. xDAI/wxDAI holders can deposit xDAI/wxDAI in https://agave.finance/sdai/, in return for sDAI, and their corresponding shares in the vault are recorded.
    2. Bridge Interest Receiver receives interest from mainnet and distribute to sDAI vault.
    3. sDAI holders withdraw/redeem xDAI/wxDAI (interest+original amount) according to their shares, that has gone up because of the interest received in step 2

Keeper

  1. Call investDAI() refillBridge() payInterest(). On Ethereum, anyone is allowed to investDAI() into the sDAI vault, anyone is allowed to refillBridge() right back up to the threshold, and also anyone is allowed to payInterest(). These processes are permissionless, and it’s also costly which is why we will have a bot to automate these 3 maintenance procedures in the most efficient way possible.
  2. Keeper is maintained by Karpatkey team. Source Code

Contracts​

ContractAddress
sDAI0x83F20F44975D03b1b09e64809B757c47f942BEeA
DAI0x6B175474E89094C44Da98b954EedeAC495271d0F
Keeper0xC5cD1e53839eeD4d0A38f80C610e77bD07120c90

Fees & Daily Limits​

TypeEthereum -> GnosisGnosis -> Ethereum
Approx. Gas Cost
Bridge Fees0%0%
Min Transfer0.005 Dai10 xDai
Daily Limit10,000,000 Dai10,000,000 xDai
Max Single Deposit9,999,999 Dai10,000,000 xDai
note

Daily Limit is reset according to the following logic: the smart contract stores total amount of processed tokens per current day and reverts on a new transfer if it exceeds the daily limit. Id of the day is calculated using the formula timestamp / (number of seconds in 1 day), where timestamp is the Unix timestamp.

Bridge Validators​

The xDai bridge relies on trusted xDai Bridge Validators as cross-chain bridge oracle. There is a roadmap to move towards trustless bridges.

Bridge transactions currently requires signatures from 4 of 7 validators.

OrganizationGnosis Address
GnosisDaogno:0x97630e2ae609d4104abda91f3066c556403182dd
Protofiregno:0x4d1c96b9a49c4469a0b720a22b74b034eddfe051
CowProtocolgno:0x587c0d02b40822f15f05301d87c16f6a08aaddde
Givethgno:0xc073C8E5ED9Aa11CF6776C69b3e13b259Ba9F506
GnosisSafegno:0x1312e98995bbcc30fc63db3cef807e20cdd33dca
Karpatkeygno:0xfa98b60e02a61b6590f073cad56e68326652d094
Gatewaygno:0x3e0A20099626F3d4d4Ea7B0cE0330e88d1Fe65D6

Bridge Validator Flow​

Bridge Governance​

Bridge Revenue​

The xDai bridge currently generates bridge revenue through earned yield on stablecoins deposited on the bridge, which is then used by the GnosisDAO treasury to fund Gnosis development.

Analytics​

How it Works​

Ethereum -> Gnosis Chain.​

The xDai token is minted when Dai is transferred from Ethereum to Gnosis using the xDai Bridge. During the transfer process, a block reward contract is invoked to mint xDai to a user's account. Because contract calls are made from the consensus engine to create xDai tokens, balance updates are more difficult to trace than simple value transfers.

  1. Users lock an amount of DAI on the bridge contract on Ethereum
  2. UserRequestForAffirmation event is triggered
  3. Validators observe the deposit and invoke executeAffirmation function on Gnosis bridge contract
  4. When enough confirmations are collected (4/7 majority), the bridge contract on Gnosis Chain calls the block reward contract to record the receiver(s) and amount(s) of xDAI to mint.
  5. The block reward contract is called by the consensus engine to update user's xDAI balance.

You can view a receiver's address and amount of xDai received in the block reward contract's logs. Whenever the executeAffirmation method is called, it registers the following:

AddedReceiver(
	uint256 amount,
	address indexed receiver,
	address indexed bridge
)

Example: https://blockscout.com/xdai/mainnet/tx/0x5892a695860f6087a2d93140f05e6365142ff77fd7128e39dbc03128d5797ac4/logs

Gnosis Chain -> Ethereum.​

  1. User -> Gnosis Chain bridge: initiate a withdrawal: xDAI is burned.
  2. UserRequestForSignature event emitted (see example transaction).
  3. Validators listen to the event: call submitSignature on Gnosis chain.
  4. After consensus: CollectedSignatures event is emitted
  5. Anyone can execute the withdrawal on Ethereum (user via UI or validator). DAI is unlocked.
  6. RelayedMessage emitted on mainnet
note

This final step may be delayed if Ethereum mainnet is congested.

References:

Managing Bridge Contracts​

Upgrading a Contract​

There are two possible scenarios for how the bridge or validators contracts can be upgraded:

  • a security fix when only the contract implementation is changed
  • an improvement when the contract implementation upgrade requires initialization of storage values.

Basic Process​

  1. One of the multisig wallet owners ABI encodes a method call with parameters (if any). This can be done with the ABI Encoding Service. The encoded sequence of bytes is used to create a transaction for the multisig wallet contract. This is done with the submitTransaction method of the multisig wallet contract.
  2. The method raises the event Submission containing the index of the registered transaction. The index is shared with the other owners of the wallet.
  3. The rest of the owners confirm the transaction by invoking confirmTransaction from the multisig wallet contract.
  4. As soon as enough confirmations are received, the method encoded in step 1 is invoked automatically. This is important because adequate gas limits must be set for that transaction and set of confirmations sent by the wallet owner finalizing the operation. If the method is not invoked because the gas limit is exceeded, the owners can execute the confirmed transaction manually by sending executeTransaction.

Security Upgrade​

  1. Deploy a new implementation of the bridge or validators contract.
  2. Depending on the contract and the chain use one of the links below to get the current version of the contract implementation:
  3. Use the upgradeTo method from EternalStorageProxy ABI, the address of the new implementation, and the incremented version number to encode the data for the transaction. Example of the data: 3ad06d160000000000000000000000000000000000000000000000000000000000000004000000000000000000000000f097137c7ec5e582b5704065f72ac5903d0b526d.
  4. Invoke submitTransaction of the multisig wallet contract (0xff1a8EDA5eAcdB6aAf729905492bdc6376DBe2dd on Mainnet ETH, 0x0d3726e5a9f37234d6b55216fc971d30f150a60f on Gnosis chain). The data field must be filled with the bytes received from the previous step. The destination depends on the contract:
    • 0x4aa42145Aa6Ebf72e164C9bBC74fbD3788045016 if the security upgrade is made for the bridge contract on ETH Mainnet.
    • 0xe1579dEbdD2DF16Ebdb9db8694391fa74EeA201E if the security upgrade is made for the validators contract on the ETH Mainnet.
    • 0x7301cfa0e1756b71869e93d4e4dca5c7d0eb0aa6 if the security upgrade is made for the bridge contract on the xDai chain.
    • 0xb289f0e6fbdff8eee340498a56e1787b303f1b6d if the security upgrade is made for the validators contract on the xDai chain.
  5. Identify the index of the transaction returned in the Submission event as soon as the transaction from the previous step is included into a block and share it with the other multisig wallet owners.
  6. (for the rest of owners) Invoke confirmTransaction on the multisig wallet contract (0xff1a8EDA5eAcdB6aAf729905492bdc6376DBe2dd on the Mainnet ETH, 0x0d3726e5a9f37234d6b55216fc971d30f150a60f on Gnosis chain). Set the gas limit to three times bigger than the gas estimator function suggests.

Bridge Improvement​

  1. Identify the method to call as part of the new implementation initialization. In the following steps we assume that the method's name is upgradeFrom3to4() which takes no arguments.
  2. Use the method mentioned above from the new contract implementation code or ABI to encode the data to be passed to upgradeToAndCall() method. Example of the data: 50d28adb.
  3. Deploy a new implementation of the bridge or validators contract.
  4. Depending on the contract and the chain, use one of the links below to get the current version of the contract implementation:
    • The bridge contract on the ETH Mainnet: Etherscan,
    • The validators contract on the ETH Mainnet: Etherscan
    • The bridge contract on Gnosis Chain: Blockscout
    • The validators contract on Gnosis chain: Blockscout
  5. Use the upgradeToAndCall method from the EternalStorageProxy ABI, the address of the new implementation, and the incremented version number to encode the data for the transaction. Example of the data: 0xa9c45fcb0000000000000000000000000000000000000000000000000000000000000004000000000000000000000000692a70d2e424a56d2c6c27aa97d1a86395877b3a0000000000000000000000000000000000000000000000000000000000000060000000000000000000000000000000000000000000000000000000000000000450d28adb00000000000000000000000000000000000000000000000000000000.
  6. Invoke submitTransaction on the multisig wallet contract (0xff1a8EDA5eAcdB6aAf729905492bdc6376DBe2dd on Mainnet ETH, 0x0d3726e5a9f37234d6b55216fc971d30f150a60f on Gnosis chain). The data field must be filled with the bytes received on the previous step. The destination depends on the contract:
    • 0x4aa42145Aa6Ebf72e164C9bBC74fbD3788045016 if the security upgrade is made for the bridge contract on ETH Mainnet.
    • 0xe1579dEbdD2DF16Ebdb9db8694391fa74EeA201E if the security upgrade is made for the validators contract on ETH Mainnet.
    • 0x7301cfa0e1756b71869e93d4e4dca5c7d0eb0aa6 if the security upgrade is made for the bridge contract on Gnosis chain.
    • 0xb289f0e6fbdff8eee340498a56e1787b303f1b6d if the security upgrade is made for the validators contract on Gnosis chain.
  7. Identify the index of the transaction returned in the Submission event as soon as the transaction from the previous step is included into a block and share it with other multisig wallet owners.
  8. (for the rest of owners) Invoke confirmTransaction() of the multisig wallet contract (0xff1a8EDA5eAcdB6aAf729905492bdc6376DBe2dd on Mainnet ETH, 0x0d3726e5a9f37234d6b55216fc971d30f150a60f on Gnosis chain). Set the gas limit to four times bigger than the gas estimator suggests.

References:

Resources​